Celestin Apprentice 2

home *** CD-ROM | disk | FTP | other *** search

/ Celestin Apprentice 2 / Apprentice-Release2.iso / Information / Digests / CSMP Digest / volume 3 / csmp-digest-v3-071 < prev next >

Wrap

Text File | 1994-12-08 | 44.9 KB | 832 lines | [TEXT/R*ch]

ort JMPInstruction; void *defProc; } GenericMDEF; #if defined(powerc) || defined(__powerc) #pragma options align=reset #endif Without them, you'll get two bytes of padding between the short and the void *. /Bo Lindbergh +++++++++++++++++++++++++++ >From Graham@impro.demon.co.uk (Graham) Date: Wed, 9 Nov 1994 17:02:12 GMT Organization: N/A I use the following routines to do this- on 68K macs it defaults to the old way of creating a stub for the jump, on PowerMacs it creates a routine dscriptor, so the same code works in all cases. try it. #include "MixedMode.h" typedef struct { short Jmp; // jmp instruction void* Routine; // address to jump to } JmpInstructionTemplate; Handle GetUniversalFunctionHandle(ProcPtr functionAddress,ProcInfoType pInfo); void PatchJmpInstruction(void* patchAddress, void* jumpAddress); Handle GetUniversalFunctionHandle(ProcPtr functionAddress,ProcInfoType pInfo) { Handle pHNullProc = NULL; ISAType isa; UniversalProcPtr axDEFUPP; isa = GetCurrentISA(); if (isa == kPowerPCISA) { pHNullProc = NewHandle(sizeof(RoutineDescriptor)); axDEFUPP = NewRoutineDescriptor(functionAddress,pInfo,isa); BlockMove(axDEFUPP, *pHNullProc, sizeof(RoutineDescriptor)); DisposeRoutineDescriptor(axDEFUPP); } else { pHNullProc = NewHandle(sizeof(JmpInstructionTemplate)); PatchJmpInstruction(*pHNullProc, (void*)functionAddress); } return(pHNullProc); } void PatchJmpInstruction(void* patchAddress, void* jumpAddress) { JmpInstructionTemplate* aJmpInstructionPtr; aJmpInstructionPtr = (JmpInstructionTemplate *) patchAddress; aJmpInstructionPtr->Jmp = 0x4EF9; aJmpInstructionPtr->Routine = jumpAddress; } You have to pass the proc info type for the routine, which youll have to look up in the universal headers, and the proc ptr to your MDEF function, it returns a handle which you simply stuff into the relevant defProc field. Apple DTS gave me the bones for this, so it even has the "official" stamp of approval! ************************************************************************ * MHROTD, Graham. (Sorry, I haven't got time to think of a witty signature) +++++++++++++++++++++++++++ >From rang@winternet.com (Anton Rang) Date: 10 Nov 1994 14:33:59 GMT Organization: Trillium Research, Inc. In article <Cz0FBo.FvL@demon.co.uk> Graham@impro.demon.co.uk (Graham) writes: >I use the following routines to do this- on 68K macs it defaults to the >old way of creating a stub for the jump, [...] Don't forget the posting last month from someone who had created a six-byte handle to hold their 'JMP $xxx' instruction and found that when the handle was moved by the memory manager, the i-cache wasn't flushed 'cause the handle was too small. :) -- Anton Rang (rang@winternet.com) +++++++++++++++++++++++++++ >From Bruce@hoult.actrix.gen.nz (Bruce Hoult) Date: Fri, 11 Nov 1994 05:15:43 +1200 (NZST) Organization: (none) rang@winternet.com (Anton Rang) writes: > In article <Cz0FBo.FvL@demon.co.uk> Graham@impro.demon.co.uk (Graham) writes: > >I use the following routines to do this- on 68K macs it defaults to the > >old way of creating a stub for the jump, [...] > > Don't forget the posting last month from someone who had created a > six-byte handle to hold their 'JMP $xxx' instruction and found that > when the handle was moved by the memory manager, the i-cache wasn't > flushed 'cause the handle was too small. :) I missed that one. But I've never understood why people use the "six-byte resource" trick when it's so easy to use a "ten-byte resource" trick that is I-cache safe. -- Bruce --------------------------- >From Jonathan Gary <jgary@ssd.kodak.com> Subject: Getting The PSN or Sig of AE Client Date: Tue, 8 Nov 1994 19:59:50 GMT Organization: Eastman Kodak I'm trying to get the the PSN of the process that sends me an AE. I can get the address from the event, but how do I get at the PSN? +++++++++++++++++++++++++++ >From wysocki@netcom.com (Chris Wysocki) Date: Friare fame) Pete Maruhnic (author of CA's Realizer for Windows) So only one of us ended up at Metrowerks. Still, the product is pretty much dead wrt PowerPC, as much my fault as anyone else's: a lot of the code was written in assembly language, the context-switch mechanism would probably not survive a port to the PPC, etc. It is rumored that Symantec still has plans in the Pascal arena (but as you might imagine they don't tell me that sort of thing anymore) -- John McEnerney, Metrowerks PowerPC Product Architect +++++++++++++++++++++++++++ >From RobTerrell@vmedia.com (Rob Terrell) Date: 6 Nov 1994 21:26:52 GMT Organization: Jecta Development Corp. John McEnerney said: > So only one of us ended up at Metrowerks. Still, the product is pretty > much dead wrt PowerPC, as much my fault as anyone else's: a lot of the > code was written in assembly language, the context-switch mechanism > would probably not survive a port to the PPC, etc. It is rumored that > Symantec still has plans in the Pascal arena (but as you might imagine > they don't tell me that sort of thing anymore) Yeah, there was a rumor in MacWeek regarding this. I doubt it. The Symantec folks were real arrogant on the topic of the death of Pascal at the WWDC. So, John, what's happening with Metrowerks' Pascal? I would totally abandon Think Pascal if CW supported an Object Pascal. Rob +++++++++++++++++++++++++++ >From siegel@netcom.com (Rich Siegel) Date: Mon, 7 Nov 1994 17:57:38 GMT Organization: Bare Bones Software In article <39j47d$gfq@spool.cs.wisc.edu> lbotez@picard.cs.wisc.edu (Lynda Botez) writes: > >Also, I think most of the programmers that developed Think Pascal are now >working for Metrowerks (the company that owns CodeWarrior); so you can >imagine that Think Pascal is not long for this world.. > That is not true. Of the four people most directly involved in the development of THINK Pascal: - one is at Metrowerks - one is director of the development tools group at Symantec - one is off doing something else (I don't recall where) - one is president and CEO of his own software company When this question was recently posted to Symantec personnel at a recent BCS MacTechGroup meeting, the response was (basically) that they plan to work with certain third-party compiler makers to produce a Pascal solution for Rainbow (their new development environment that is currently under development). R. -- Rich Siegel % siegel@netcom.com % President & CEO, Bare Bones Software Inc. --> For information about BBEdit, finger bbedit@world.std.com <-- +++++++++++++++++++++++++++ >From peter.lewis@info.curtin.edu.au (Peter N Lewis) Date: Tue, 08 Nov 1994 11:23:59 +0800 Organization: NCRPDA, Curtin University In article <39jhms$ja@redstone.interpath.net>, RobTerrell@vmedia.com (Rob Terrell) wrote: >Yeah, there was a rumor in MacWeek regarding this. I doubt it. The >Symantec folks were real arrogant on the topic of the death of Pascal >at the WWDC. A Symantec fellow told me that the rumour is crap. There is no Symantec plans for a PPC pascal compiler. >So, John, what's happening with Metrowerks' Pascal? I would totally >abandon Think Pascal if CW supported an Object Pascal. You and me both. I'm strugling on with THINK Pascal waiting for objects to show up in MW Pascal. MW Pascal is scheduled to go 1.0 without objects in January (CW5), and MW Object Pascal is scheduled for CW6 in May (it better be there, otherwise Greg will have to face down some heckling at the WWDC :-). The best you can do to help is to a) make sure MW knows that Object Pascal is what you need; b) buy MW CW; c) feed any bugs back to the MW bug report line as precisely as you can. That's what i've been doing, an Marcel has been very good at fixing bugs (such that basically every bug I have reported has been fixed by the next version). Enjoy, Peter. -- Peter N Lewis <peter.lewis@info.curtin.edu.au> - Macintosh TCP fingerpainter FTP my programs from redback.cs.uwa.edu.au:Others/PeterLewis/ or amug.org:pub/peterlewis/ or nic.switch.ch:software/mac/peterlewis/ ++++++++++++++++uld be released once I'm finished with it but, again, this function doesn't do that. Am I wrong, is this function wrong, or is it simply not necessary, in this case, to release the resource? FUNCTION setResStr(rsrcType:ResType; rsrcID:INTEGER; content:STR255):OSErr; VAR rsrcHdl : Handle; result : OSErr; BEGIN rsrcHdl := GetResource(rsrcType, rsrcID); result := ResError; IF (rsrcHdl <> NIL) THEN BEGIN SetHandleSize(rsrcHdl, LENGTH(content) + 1); BlockMove(@content, rsrcHdl^, LENGTH(content) + 1); ChangedResource(rsrcHdl); result := ResError; IF (result = NoErr) THEN BEGIN WriteResource(rsrcHdl); result := ResError; END; END; setResStr := result; END; {setResStr} Any help, hints, tips, suggestions would be appreciated. Roxanne. -- Roxanne Friesen Bell-Northern Research Ltd. roxanne@bnr.ca +++++++++++++++++++++++++++ >From jones.794@osu.edu (Matt Jones) Date: Mon, 07 Nov 1994 19:15:24 +0500 Organization: The Ohio State University In article <roxanne-0711941153320001@47.221.33.54>, roxanne@bnr.ca (Roxanne Friesen) wrote: > I'm trying to get a better *handle* on when handles should be disposed of > and resources released. > > In the first sample function below, I would have thought that the alias > handle should be disposed of once the resource has been written to the > resource file but this function doesn't do that. Am I wrong, is this > function wrong, or is it simply not necessary, in this case, to dispose of > the handle? (For the sake of simplifying the samples, assume I'm writing > to my apps own resource fork and not a prefs file of some kind ... or does > that make a difference?) > > FUNCTION doCreateAlias(fileSpec:FSSpec):OSErr; > VAR > alisHandle : AliasHandle; > result : OSErr; > > BEGIN > result := NewAlias(NIL, fileSpec, alisHandle); > IF (alisHandle <> NIL) THEN BEGIN > AddResource(Handle(alisHandle), rAliasType, 128, 'File Alias'); > result := ResError; > > IF (result = NoErr) THEN BEGIN > WriteResource(Handle(alisHandle)); > result := ResError; > END; > END; > > doCreateAlias := result; > END; {doCreateAlias} > > > In the second sample function below, again, I would have thought that the > resource should be released once I'm finished with it but, again, this > function doesn't do that. Am I wrong, is this function wrong, or is it > simply not necessary, in this case, to release the resource? > > FUNCTION setResStr(rsrcType:ResType; rsrcID:INTEGER; content:STR255):OSErr; > VAR > rsrcHdl : Handle; > result : OSErr; > > BEGIN > rsrcHdl := GetResource(rsrcType, rsrcID); > result := ResError; > > IF (rsrcHdl <> NIL) THEN BEGIN > SetHandleSize(rsrcHdl, LENGTH(content) + 1); > BlockMove(@content, rsrcHdl^, LENGTH(content) + 1); > ChangedResource(rsrcHdl); > result := ResError; > > IF (result = NoErr) THEN BEGIN > WriteResource(rsrcHdl); > result := ResError; > END; > END; > > setResStr := > result; > > END; {setResStr} > > > Any help, hints, tips, suggestions would be appreciated. > Roxanne. > > -- > Roxanne Friesen > Bell-Northern Research Ltd. > roxanne@bnr.ca If your compiler is any good, it checks if any of the handles in local storage are still attached. ( I think ) Otherwise, you would be unable to find the handles to dispose of them later. However, this is tricky internal compiler stuff, much like pre-initialized variables. I always explicitly dispose of handles since the moment you assume your compiler does it for you, it stops. - ------------------------------------------------------------------------ | it won't give up it wants me dead | |\ | | | /| | jones.794 | | goddamn this noise inside my head | | \ | | | / | | @ohio-state.edu | | Trent Reznor | | \| | |/ | | Stop the Clipper! | - ------------------------------------------------------------------------ +++++++++++++++++++++++++++ >From sigurasg@rhi.hi.is (Sigurdur Asgeirsson) Date: Tue, 08 Nov 1994 09:49:56 -0100 Organization: University of Iceland In article <roxanne-0711941153320001@47.221.33.54>, roxanne@bnr.ca (Roxanne Friesen) wrote: [snip] > In the first sample function below, I would have thought that the alias > handle should be disposed of once the resource has been written to the > resource file but this function doesn't do that. Am I wrong, is this > function wrong, or is it simply not necessary, in this case, to dispose of > the handle? [snip] > FUNCTION doCreateAlias(fileSpec:FSSpec):OSErr; > VAR > alisHandle : AliasHandle; > result : OSErr; > > BEGIN > result := NewAlias(NIL, fileSpec, alisHandle); > IF (alisHandle <> NIL) THEN BEGIN > AddResource(Handle(alisHandle), rAliasType, 128, 'File Alias'); > result := ResError; > > IF (result = NoErr) THEN BEGIN > WriteResource(Handle(alisHandle)); > result := ResError; > END; > END; > > doCreateAlias := result; > END; {doCreateAlias} > > [second code example snipped for brevity] There is no need in this case to dispose the handle, unless the AddResource call fails, in which case the handle should be disposed of with DisposeHandle (since the handle is not a resource if the call fails - see below). In general there is no need to dispose of resource handles, because they are the responsibility of the Resource Manager. Resource handles must NEVER be disposed of via DisposeHandle, since that confuses the Resource Manager and you end up with heap corruption. (The Resource Manager does a DisposeHandle for all loaded resources in a resource file when the resource file is closed). If you feel the need to dispose of a resource handle when you're done with it (maybe because you'd like to free the memory that the resource is using) do it with the ReleaseResource call. It's generally better though to mark your resources as purgeable and leave it up to the Memory and Resource Managers to free the memory when needed. Be sure however, to use LoadResource in this case and mark the resource unpurgeable (or lock it) if you need to be sure that it doesn't "go away" while you're using it. -- Sigurdur Asgeirsson | "Well you know, C isn't that hard, void (*(*f[])())() Kambasel 26 | for instance declares f as an array of unspecified 109 Reykjavik, Iceland | size, of pointers to functions that return pointers to sigurasg@rhi.hi.is | functions that return void... I think" +++++++++++++++++++++++++++ >From johns@efn.org (John Selhorst) Date: Tue, 8 Nov 1994 14:43:55 GMT Organization: hisself In article <jones.794-071194191524@slip1-12.acs.ohio-state.edu>, jones.794@osu.edu (Matt Jones) wrote: [ stuff from Roxanne deleted ] > If your compiler is any good, it checks if any of the handles in local > storage are still attached. ( I think ) Otherwise, you would be unable to > find the handles to dispose of them later. However, this is tricky internal > compiler stuff, much like pre-initialized variables. I always explicitly > dispose of handles since the moment you assume your compiler does it for > you, it stops. Wrong. This is not fancy compiler stuff. The handles Roxanne was referring to belong to the resource manager and the resource manager will dispose of them when it needs to. Johnny johns@efn.org +++++++++++++++++++++++++++ >From Scott.Francis@SuperMac.com (eScott Francisternet alt.bbs.lists alt.bbs.lists.d alt.bbs.majorbbs alt.bbs.metal alt.bbs.pcboard alt.bbs.pcbuucp alt.bbs.renegade alt.bbs.searchlight alt.bbs.unixbbs alt.bbs.unixbbs.uniboard alt.bbs.uupcb alt.bbs.waffle alt.bbs.wildcat alt.beadworld alt.) Date: Tue, 08 Nov 1994 10:49:31 -0800 Organization: Radius In article <roxanne-0711941153320001@47.221.33.54>, roxanne@bnr.ca (Roxanne Friesen) wrote: > I'm trying to get a better *handle* on when handles should be disposed of > and resources released. > In both cases the resource handle should be released with ReleaseResource(). Many programmers have not always done so, particularly when building apps since the res file will be closed (and all resources from that file released) when the app quits. While calling ReleaseResource() is then not strictly necessary, it is good form, and can help some types of memory problems. Another dimension to the problem: If you will be refetching resources again and again, you might want to make the preloadable, and *not* release them. This will keep them in memory and speed up the calls to GetResource(). --Scott +++++++++++++++++++++++++++ >From mxmora@unix.sri.com (Matt Mora) Date: 8 Nov 1994 15:39:07 -0800 Organization: SRI International, Menlo Park, CA In article <roxanne-0711941153320001@47.221.33.54> roxanne@bnr.ca (Roxanne Friesen) writes: >I'm trying to get a better *handle* on when handles should be disposed of >and resources released. Simple. Handle are disposed and Resources are released. >BEGIN > result := NewAlias(NIL, fileSpec, alisHandle); > IF (alisHandle <> NIL) THEN BEGIN > AddResource(Handle(alisHandle), rAliasType, 128, 'File Alias'); At this point aliasHandle is no longer a plain ol handle. After you call Addresource the handle you supply becomes a ResourceHandle. If its a resource handle what are you supposed to do with it? Yep ReleaseResource. DON'T CALL DISPOSEHANDLE AFTER YOU CALLED ADDRESOURCE ON THAT HANDLE. > >In the second sample function below, again, I would have thought that the >resource should be released once I'm finished with it but, again, this >function doesn't do that. Am I wrong, is this function wrong, or is it >simply not necessary, in this case, to release the resource? In the example that was shown, you don't have to call release resource if you might use that resource again. If you don't want it around go ahead and call release resource. If the resource file is closed, the Resource handles will be released. Xavier -- ___________________________________________________________ Matthew Xavier Mora Matt_Mora@sri.com SRI International mxmora@unix.sri.com 333 Ravenswood Ave Menlo Park, CA. 94025 +++++++++++++++++++++++++++ >From mxmora@unix.sri.com (Matt Mora) Date: 8 Nov 1994 15:40:13 -0800 Organization: SRI International, Menlo Park, CA In article <jones.794-071194191524@slip1-12.acs.ohio-state.edu> jones.794@osu.edu (Matt Jones) writes: >If your compiler is any good, it checks if any of the handles in local >storage are still attached. ( I think ) Otherwise, you would be unable to >find the handles to dispose of them later. However, this is tricky internal >compiler stuff, much like pre-initialized variables. I always explicitly >dispose of handles since the moment you assume your compiler does it for >you, it stops. Huh? Xavier -- ___________________________________________________________ Matthew Xavier Mora Matt_Mora@sri.com SRI International mxmora@unix.sri.com 333 Ravenswood Ave Menlo Park, CA. 94025 +++++++++++++++++++++++++++ >From peter.lewis@info.curtin.edu.au (Peter N Lewis) Date: Wed, 09 Nov 1994 11:27:40 +0800 Organization: NCRPDA, Curtin University In article <roxanne-0711941153320001@47.221.33.54>, roxanne@bnr.ca (Roxanne Friesen) wrote: >In the first sample function below, I would have thought that the alias >handle should be disposed of once the resource has been written to the >resource file but this function doesn't do that. Am I wrong, is this >function wrong, or is it simply not necessary, in this case, to dispose of >the handle? (For the sake of simplifying the samples, assume I'm writing >to my apps own resource fork and not a prefs file of some kind ... or does >that make a difference?) First off, you must never call DisposeHandle on a resource handle, nor ReleaseResource on a non-resource handle. Bad THings(tm) will happen. There are a pair fo inits (DoubleTrouble and DisposeResource or some such) that catch bugs like this, available from ftp.apple.com:/mac/dts/ I believe. Second, when you write a resource to a file, it's not necessayr to release it afterwards, since it will be automatically released when the resource file is closed (which tends to be quite soon afterwards anyway). Also, you can set the handle to be purged (HPurge) and then it'll be released when memory is needed, but not until. Make sure to call GetResource again to reload the (possibly) purged handle before reusing it. Enjoy, Peter. -- Peter N Lewis <peter.lewis@info.curtin.edu.au> - Macintosh TCP fingerpainter --------------------------- >From fallside@rahul.net (David C. Fallside) Subject: Prograph 2.5 Date: 10 Nov 1994 06:39:19 GMT Organization: a2i network I recently accepted a $59.95 offer for Prograph 2.5. The promo blurb "Very High Level Pictorial Object-Oriented Programming Environment" seems to be accurate, and having worked my way through half of the tutorials, it seems that it should be possible to develop complex applications. But I'm not a professional programmer, and haven't found anyone else who has ever heard of Prograph. Any comments from Netland? Thank you. David ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I'd rather be on the river .... K1/4, SQRT/3 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +++++++++++++++++++++++++++ >From nick+@pitt.edu ( nick.c ) Date: Thu, 10 Nov 1994 11:42:38 -0500 Organization: The Pitt, Chemistry In article <fallside-0911942243270001@382.rahul.net>, fallside@rahul.net (David C. Fallside) wrote: > I recently accepted a $59.95 offer for Prograph 2.5. The promo blurb "Very > High Level Pictorial Object-Oriented Programming Environment" seems to be > accurate, and having worked my way through half of the tutorials, it seems > that it should be possible to develop complex applications. But I'm not a > professional programmer, and haven't found anyone else who has ever heard > of Prograph. Any comments from Netland? Thank you. Prograph was my first environment (not counting hypercard), and I consider that a mistake. Don't get me wrong - prograph is both a great concept and a great engineering feet. I still argue that inconic input will be the way we'll all code 10 years from now (or sooner). However, prograph is a dual mode environment, it allows you to program at a low level, but defaults to a high level environment by use of it's integrated class library. As a result, and with the added factor there is very little sample code or literature, it's hard to tell where the library ends and the toolbox begins. You can generate nice (albeit large and slow) apps with 2.5.2 - nicer ones with CPX - but you won't learn anything about Mac programming with it. To learn how to program the Mac you'll need to learn a classical low level language (Pascal or C would be best), and when you do you'll find you can generate much smaller, faster binaries and have access to a wealth of established library code and example code from all over the world. My guess is most "professional" programmers, don't want to give up those advantages. Prograph was marketed as a non-programmers programming language, and I think that's still true. However, as I said above, it does allow low level coding, is very powerfull, and has the best interface and debugger I've ever seen. It's a glimpse of the future of programming, and worth knowing, just remeber you get paid in the present. Internet: nick+@pitt.edu _/ _/ _/ _/_/_/ _/ _/ eWorld: nick _/_/ _/ _/ _/ _/ _/_/_/ CIS: 71232,766 _/ _/_/ _/ _/ _/ _/ http://www.pitt.edu/~nick/ _/ _/ _/ _/_/_/ _/ _/ +++++++++++++++++++++++++++ >From pjensen@netcom.com (Peter Jensen) Date: Thu, 10 Nov 1994 16:53:40 GMT Organization: NETCOM Oname? 2. What function calls should I use to be able to access a single frame? In the Inside the Mac it says that a programmer can access every frame. How? 3. Where does QuickTime store information about the frame rates (fps) of a movie? For example the frame rate that a movie was created with? 4. Is there a realtionship between frame rate (fps) and playback rate? 5. When QuickTime does not have enough time to display all the frames of a movie, it starts dropping frames. Is there a pattern to this frame dropping? For example does it drop everyother frame, or the third in every 3 frames? How does it decide which frames to drop? thanx Ladan +++++++++++++++++++++++++++ >From rich@cs.umd.edu (Richard Gerber) Date: 2 Nov 1994 19:44:03 -0500 Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 I am interested too. But specifically: from within a quicktime player is there any way to dynamically determine -- as the movie is playing -- which particular frames are being dropped. If not, what's the lowest level of granularity I can get to? rich - ---------- Richard Gerber Assistant Professor Department of Computer Science University of Maryland College Park, MD 20742 USA Email: rich@cs.umd.edu Tel: (301) 405-2710 FAX: (301) 405-6707 +++++++++++++++++++++++++++ >From ivan_cavero_belaunde@avid.com (Ivan Cavero Belaunde) Date: 8 Nov 1994 00:00:42 GMT Organization: Avid Technology, Inc. In article <3998qv$7id@mingus.cs.umd.edu>, ladan@cs.umd.edu (Ladan Gharai) wrote: > Hi everyone > > I am new to the QuickTime and am trying to understand how it works. I have > a bunch of questions and would appreciate any answers. I need to write a player > with very specific functionality. Going through the Inside the Mac: Quicktime > I have the following questions: > > 1. A sample is defined as "A single element of a sequence of time-ordered > data" does this mean that for a vedio a sample would be a frame? Yup. > 2. What function calls should I use to be able to access a single frame? In the > Inside the Mac it says that a programmer can access every frame. How? If I want the sample at time 10 on the first track: theTrack = GetMovieIndTrack(theMovie, 1); theMedia = GetTrackMedia(theTrack); mediaTime = TrackTimeToMediaTime(theTrack, 10); if (mediaTime != -1) { err = GetMediaSample(theMedia, sampleDataHandle, 0, &sampleDataSize, mediaTime, nil, nil, sampleDescriptionHandle, nil, 1, nil, &sampleFlags); > > 3. Where does QuickTime store information about the frame rates (fps) of a movie? > For example the frame rate that a movie was created with? It doesn't since the frame rate can vary over time throughout the movie. You can estimate it by walking each track by track edits via GetTrackNextInterestingTime and then figuring out the frame rate for each edit by looking at the edit rate for each edit as well as the durations of the samples spanned by the edit. > 4. Is there a realtionship between frame rate (fps) and playback rate? I'm not sure what you mean here. The QuickTime movie will never play at a better rate than its original stored rate - additionally, it is eminently possible to create a movie with too high a stored frame rate that will not play properly and will drop frames. > 5. When QuickTime does not have enough time to display all the frames of a > movie, it starts dropping frames. Is there a pattern to this frame dropping? > For example does it drop everyother frame, or the third in every 3 frames? > How does it decide which frames to drop? A movie has a "running clock" that tells it what "time" it is within the movie. When falling behind, QT will drop as many frames as necessary to catch up the frame being displayed with its running clock. The results are dependent on boatloads of factors, such as the horsepower of your machine, the bandwidth of your storage device, the seek speed of your storage device, the compression scheme used, the frame-differencing characteristics of the movie, and where within the movie the "playback head" is. There's no simple answer, sorry. Hope this helps. Followups redirected to comp.sys.mac.programmer. -Ivan - -- Ivan Cavero Belaunde (ivan_cavero_belaunde@avid.com) Avid VideoShop Lead Avid Technology, Inc. Disclaimer: All views expressed are entirely my own and do not reflect the opinions of Avid Technology, Inc. --------------------------- End of C.S.M.P. Digest **********************